The present invention generally relates to design model processing and more particularly to a system and a method for converting a design model into code.
In the process of developing computer software, an architecture design needs to be conducted in an appropriate manner by performing an accurate analysis and abstraction of the system specification based on the requirements for a specification of the design target. In this phase of software development, it is well known to use graphical modelization, using a standardized specification language such as the Unified Modeling Language (UML). UML is a design method including an abstraction of the design target, a visualization, a specification determination, and a drafting of documents related to the design.
The models created with UML, such as the class diagrams, are derived to actual programming code. UML is generally used for object oriented development but is more commonly adopted by the industry for high level software design. The benefits of using UML during the design phases of software development and describing software artifacts include the ability to conduct design review with a commonly accepted, high design language. It allows for capturing the critical information that describes the application without detailing it down to the implementation level, and applying Model Driven Architecture techniques that provide code generation.
Describing an application involves describing the data structures that it manipulates and the flow of actions and operations that the application performs. In an object oriented language, made up of several classes that interact with each other and of code dispatched through several methods of each class. The control flow of the application involves various interactions between methods of various classes. In a procedural language, an application is defined by a main program that can interact with others. The control flow is mainly defined within each program.
An activity diagram is one of the behavioral diagrams in UML and is used to capture dynamic aspects of the system. It is well suited to capture a high level description of the control flow of a program, especially written in a procedural language.
UML activity diagram can therefore be used to capture the control flow of a program. From there, it is valuable to generate a skeleton of code from the activity diagram in order to translate the information it contains into source code that would be enhanced by a developer. However, the nature of the activity diagram, being an oriented graph, makes it difficult to apply a method and transform its contents into code, which is sequential by nature.
One known solution to this problem is the approach taken in the article by Philip Mayer, Andreas Schroeder, and Nora Koch entitled “A Model-Driven Approach to Service Orchestration” for Institute for Informatics, July 2008. This solution is based on the well-known depth-first search algorithm and provides a method to identify branches, loops and parallel flows in an activity diagram and transform such an activity diagram into code (BPEL). However, this solution has several constraints that must be followed in order to be able to generate some code from the activity diagram. In particular, the user is required to use dedicated patterns of nodes in order to represent decisions or loops. In particular, a condition needs to be “balanced”, which involves ending with a merge node and a loop needs to start or end with a merge node.
This solution thereby introduces constraints during the software development process while architects need to focus on the functions they want to achieve instead of their representation. Further, they need to be able to draw the flow of actions of their programs as freely as possible. These constraints also impose to design the activity diagram—which is a graph and in other words a non linear construct—in a linear way, with a single start and end. The dedicated patterns of nodes, such as merge nodes, required by this solution are generally optional constructs in a UML diagram: it is possible to draw a UML diagram without necessarily involving them. Actually, most diagrams do not use merge node except when it is desired to explicitly state the merge as semantically important. Having to involve unnecessary nodes in the process, and writing a graph in a linear way constitute significant constraints in the development process. This renders code generation inapplicable in practice.
Another solution to this problem is described in the article entitled “An algorithm for structuring flowchart”, by Brenda S. Baker, Journal of the Association for Computer Machinery, Vol. 24, January 1977. This solution provides a method to generate code from a graph. The purpose is to process existing FORTRAN programs to facilitate their maintenance, and represent the FORTRAN program in a graph that is then processed to produce a more readable version of the code. This method does not require that a decision node would be closed later in the graph, and thereby does not require a specific type of closing node. However, this method does not deal efficiently with balanced decision nodes. Further, the input of this method is existing FORTRAN source code. The graph is obtained from this existing FORTRAN source code in order to create better FORTRAN code. This solution is therefore not adapted for situations where the graph is not obtained from existing source code. Further, this solution applies the in-depth graph processing algorithm, which does not make any distinction between arcs of a graph that are balanced and represent a set of instructions that fork then merge. It considers each fork in the graph to represent an unconditional transfer of control (GOTO).